Kill an incumbent daemon that ignores SIGTERM - #13
Merged
Conversation
The five-second wait ended by giving up, which cannot be what happens: the SIGTERM has already been delivered by then, so the incumbent dies as soon as it is unwedged, and the newcomer has just exited. The outcome was zero daemons and a log line claiming the old one still had the hotkey. Escalate to SIGKILL instead. Anything still holding the lock five seconds after a SIGTERM is wedged rather than busy — a clean exit is a few file writes — and the kernel drops the lock with the process, so the newcomer takes it and there is exactly one daemon either way. If the one killed was the login job, launchd brings it back and the two settle it the ordinary way; one of them holds the lock, never both. Verified: incumbent frozen with SIGSTOP, second daemon started — logs "ignored SIGTERM — killing it", the frozen pid is gone, and one process is left listening.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #12, which got this branch wrong.
The five-second wait ended in
return false— "leaving it the hotkey". It cannot leave it the hotkey: the SIGTERM was delivered before the wait started, so the incumbent dies the moment it is unwedged, and the newcomer has already exited. The real outcome was zero daemons, described by a log line saying the old one still had it.Escalate to SIGKILL instead. Anything still holding the lock five seconds after a SIGTERM is wedged rather than busy — a clean exit is a few file writes — and the kernel releases the lock with the process, so the newcomer takes it. One daemon either way, which is the entire point of the lock. If the one killed was the login job, launchd sees the abnormal exit and brings it back; it then finds the lock held and the two settle it the ordinary way, so one of them ends up holding it and never both.
Only a signal the kernel refuses (
killfailing with something other thanESRCH) still ends inreturn false.Verification
Incumbent frozen with
kill -STOPso it cannot answer SIGTERM, then a second daemon started:The frozen pid is gone and exactly one process is left listening. Previously the same test left the newcomer dead, the frozen daemon doomed, and nothing on the hotkey.